Raphael Geissert: A bashism a week: returning
Inspired by Thorsten Glaser's comment about where you can break from, this "bashism a week" is about a behaviour not implemented by bash.
return is a special built-in utility, and it should only be used on functions and scripts executed by the dot utility. That's what the POSIX:2001 specification requires.
If you return from any other scope, for example by accidentally calling it from a script that was not sourced but executed directly, the bash shell won't forgive you: it does not abort the execution of commands. This can lead to undesired behaviour.
A wide variety of shell interpreters silently handle such calls to return as if exit had been called.
An easy way to avoid such undesired behaviours is to follow the best practice of setting the e option, i.e.
The POSIX specification does not guarantee the above behaviour either as the result in such cases is "unspecified", however.
return is a special built-in utility, and it should only be used on functions and scripts executed by the dot utility. That's what the POSIX:2001 specification requires.
If you return from any other scope, for example by accidentally calling it from a script that was not sourced but executed directly, the bash shell won't forgive you: it does not abort the execution of commands. This can lead to undesired behaviour.
A wide variety of shell interpreters silently handle such calls to return as if exit had been called.
An easy way to avoid such undesired behaviours is to follow the best practice of setting the e option, i.e.
set -e. With that option set at the moment of calling return outside of the allowed scopes, bash will abort the execution, as desired.
The POSIX specification does not guarantee the above behaviour either as the result in such cases is "unspecified", however.